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Foreword 

This Technical Report has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

There is a need to enhance the privacy mechanisms provided for Location Services to support the increasing number of 
LCS clients and the varying privacy requirements for location services. It should also be possible for the subscriber to 
set or change the location related privacy parameters in the home network. There are some limitations in support for 
user privacy in the current LCS specifications in 3GPP and there is a need to enhance the privacy mechanisms e.g. for 
roaming subscribers. 
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1 . Scope 

This Technical Report for Rel-5 identifies and describes enhanced user privacy in location services (LCS) and the 
corresponding functional requirements. The TR describes some possible enhancements to the privacy mechanisms 
provided for Location Services to support the increasing number of LCS clients and the varying privacy requirements 
for location services. The TR describes the stage-2 type of functional requirements for enhancing user privacy in 
location services that may be moved to the LCS Stage 2 specification TS 23.271, as seen feasible by TSG SA2. 

The b asic network solution as standardized in TS 23.271 Release 5 is described in general terms in the TR. with an 
indication of what enhanced privacy features are supported in Rel-5. The further enhanced LCS privacy features in Rel- 
6 and some alternative network solutions to supp o rt user privacy in Release 6 are also described and compared. 

It should be not ed that the GM LC-GMLC interface (Rel-6^ is not taken into account in most network alternative 
described in this report. — 

This TR defines the enhanced support of user privacy in location services regarding: 

- General description of enhanced user privacy in location services 

- Definition of enhanced user privacy in location services capabilities 

- Functional requirements Charging aspects 

- Security aspects 

- Roaming, service availability and continuity 

- Relation between privacy issues in Presence and Location services. 



2. References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPPTS 22.071 

[2] 3GPPTS 23.271 



3. Definitions, symbols and abbreviations 
3.1 Definitions 

Codeword: Target Subscriber defined access code, which must be provided by requestor in order not to get the location 
request rejected. The codeword is privacy information. 
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Privacy profile register (PPR): a functional entity containing a database with subscriber privacy information for 
location services and functionality to perform the related privacy checks. Note: the PPR is used in the architectural 
alternatives described in sect. 7. 1 and 7.2. 

Requestor: the originating entity, which has requested the location of the target UE from the LCS client. 

Requestor Identity: This identifier is identifying the Requestor and can be e.g. MSISDN or logical name. 

Service Type: The LCS Server maps the services indicated by an LCS Client into a Service Type as specified in TS 
22.071. 

Service Identity: Identity of the service under certain LCS Clients 
User: The subscriber and user of the target UE 



3.2 Abbreviations 

PPR Privacy Profile Register 



4. General description 

In current Specifications only limited screening for privacy is possible. The screening is based on the "LCS client ID** 
parameter of MAP Provide Subscribe Location message used by GMLC to request the subscriber's location from SGSN 
or MSC. The visited MSC or SGSN maps the received LCS client ID to subscriber's Privacy parameters (e.g. list of 
allowed LCS clients) to screen out the unwelcome location requests. In practise, there is a need to have more detailed 
service type screening e.g. to differentiate between "where am I" type of services and games or entertainment services. 

Additionally, it will be difficult for a subscriber to use local location based services when roaming. The subscriber does 
not have proper means to add local LCS clients to the allowed LCS client list in the Home environment HLR. 
Furthermore, the privacy parameters are defined with quite a narrow scope in the HLR, which may make it difficult for 
the subscriber to set additional and varying privacy parameters per LCS client. 

According to the current specifications, the subscriber cannot receive any information regarding who originally asked 
for the location of the subscriber. Subscribers should be notified about the Requestor identity and it should be possible 
to allow the location information to be given only to those requestors, who are entitled to have it. All subscribers* 
location information should anyhow be protected against unwelcome location requests. 

In order to protect the UE against the unwelcome location requests, the LCS shall support the screening function which 
denies the unwelcome accesses to UE The current LCS specification only supports the screening mechanism using the 
external identity of the LCS client and there is a need to enhance the screening mechanism e.g. using "Allowed 
Requestor List" or "Codeword". 



5. Functional Description and Functional Requirements 
5.1 Service Type Privacy 

The user may wish to differentiate between privacy requirements even with one LCS Client, depending on which 
service the user requests from this LCS client or which service the LCS client offers to the user. 

The LCS client requests location information for a target UE from GMLC. Currently the location request contains at 
least efuV the identity of the LCS client and the identity of the target UE. The LCS client request is screened by GMLC 
using the identity of the LCS client. The screening mechanism is enough for the basic type of location requests, but 
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there is a need to enhance the functionality of the mechanism because one single LCS client may offer or support 
several or a multitude of different services. It is clear that the target UE user will have different privacy demands for 
different services, even when only one LCS client offers the services. 

The enhanced mechanism should enable the users to allow their location information to be given to all LCS clients 
providing an indicated type of service. The user could e.g. allow all dating type services to get location information The 
location request message issued by the LCS client to GMLC may_ could b o enhanced to include a service identity which 
canweukMhen be interpreted by GMLC to indicate what services belong to a certain Service Type category The 
subscriber should be able to define and set privacy rules based on service type, so that services under that service type 
can be handled according to the corresponding service type privacy setting. 

The service requirements for service type privacy and the standardized service types are specified in TS 22 07 1 f 1 1 The 
service type functionality wiUweeld allow subscribers to use location services more easily while roaming ' 

^?!™"???f C ^u be J S ?" "f a " attribUte ° f the LCS Client and the LCS client name coul « contain the service type 
^g^^^ in J uscful WQ y and » t shall be possible to verify that the service identitvt vpe indicated 

Thoro arc oppooito views regarding whether the service typ e chock may bo dono in the network or only by 



Note: 



Service type checking by the target would be a "looser" way of defining services, and allowing users and client more 
freedom in def.n.ng services, while service type checking by the network would require some standardization but 
would allow the network to control "spamming" towards the target. 

Sen-ice typo chocking on application level avoids unnecessary sfgnatiwg in mm network, i e fitters o ut th e Lo c ati on 
r e quests that anyway are going to be rejected. 

fa-addrtkm -It is noted that application/content providers probably could sunnort can ^ nffnri™ { i f , 
tn i s kind ot propnetarv application based servirc identity privacy without waiting for Rel-5 of 3GPP. 

It is «nph^ized that the service types offered by a certain LCS Client is to be part of the LCS Client service profile, 
which shallbe known by the GMLC. An LCS client is hence not able to claim to offer services that are not included in 
its profile. The service type shou!d_eafl^seK>nly be conveyed between PLMNs with valid roaming agreements. 

The LCS Server (PLMN) shall map the service identity given by the LCS client to a service type. The operator defines 
to what service type the given service identity belongs to. 

For the benefit oi roaming uaors it is vital t o Rel-5 includes a standardized a-set of service types that can be used I 
globally m all PLMNs. It shall be possible for the network operator/service provider to define additional service types 
that need not be globally unique. It is foreseen that the defined s ervice tvnes will be further elnhnrst^ in <; a i an d 
possibly new service types added in Rel-fi \ — a - u 



5.2 Support for enhanced privacy checking 

It is seen that the current way to handle the privacy related settings in the network is probably too limited to support the 
increasing number of LCS clients and the varying privacy requirements for location services. It should also be possible 
for the user to set or change the location related privacy parameters in the home environment. S A 1 has decider! that 
Release 6 should include new flexible ways to set privacy req uirements, eg according to time" day of week and „ w 
l0cat '° n In ° r t er to « u PP ort Such additional privacy settings for location services architectural changes may be needed 
see chapter 7. Regarding privacy settings based on time of day t he time of the visited network coujd apply or e g . on,; 
universal tim e, like UTC. hut this is for further study ~ some 

For compatibility reasons to preTiel-M the MSC/SGSN and HLR privacy functionality has to be kept regarding 
call/session related class, (notification and/verification of the location reg n^a ~ E h 

The enhanced network support for flexible privacy setting s , e. g . bas ed on location, jjmg of day etc i< not included in 
the scope of Release 5. ■ 
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5.3 Requestor 

In the current 3GPP LCS specifications only the LCS client is identified and authorized when a location based 
application is requesting the position of a target UE and in the original LCS specifications the LCS client itself was the 
originator, i.e. requestor, of the location information. The GMLC may store an "Authorized UE List", which holds 
MSISDNs or groups of MSISDN of the target mobiles, for which the LCS Client may issue a location request [2]. 

Within 3GPP scope there is no mechanism for the target UE user to activate a certain application with a known LCS 
client, but still be able to restrict who are allowed to get position information regarding the target UE. A simple example 
of this type of service is a "Friends finder" application. Currently there is only a relation between the LCS client and the 
MSISDNs it is allowed to issue location request for, but there is no relation between the originating requestor and the 
target UE. This prevents the target UE user from authorizing the originating requestor. 

Not e 1: It is FFS if the r e lation betwe e n the originating r e qu e stor and the target UE could be handl e d by the 

application. Applications lik e th e "Fri e nd s finder" typical l y alr e ady today provide this kind of relation. 

TS 22.071 [1] specifies a new service requiremen t in Rel-5 . that the Location Request issued by the LCS client should 
be enhanced to optionally include also the identity of the originator of the location request, i.e. the Requestor, not only 
the identity of the LCS client. The scenario is developed such, that the requestor is connected to the LCS client as a 
separate entity, with its own identity. Because of this, also the requestor should must be authenticated by the LCS client 
and/or the n e twork . 

Not e 2: Other security asp e cts of th e Requ e stor functional i ty should b e further studi e d. 

Note-3: It is seen that when the requestors are authenticated by the LCS client, die LCS client should not use the 
same requestor identity for several requestors^- Wwhen the requestors are authenticated by GMLC the 
GMLC should not use the same requestor identity for several requestors. On the other hand, the requestor 
identity could be used to the idenufty e£a clos e d user group that could be used by and for different 
requestors, but this is for further study. 

The identity of the Requestor shall be included in the privacy interrogation request, when this is sent to the target UE 
and shown to the user. 

The basic requestor functionality is included in Rel-5 and may be further enhanced in Rel-6, see chapter 8. 
■ This functiona l ity should po ss ibly bo i ntroduc e d alr e ady in R e l 5. 

5.4 User Control 

The target user must have full control regarding who can get his or her location information. The LCS stage 1 
specification 22.071 [11 contains the following text on user control: 

"The user shall be able to change the following settings in the privacy exception list. 

the LCS Client and/or group of LCS Clients list 

the target UE user notification setting (with/without notification) 

the default treatment, which is applicable in the absence of a response from the target UE for each LCS 
client identifiers" 

In addition the user should also be able to change privacy settings for the service types, Requestors and Codewords in 
Relo and the time and location based privacy settings in Rel-6 . The mechanisms for user control are outside the scope 
of this Technical Report^ FS. 

5.5 Codeword 

The codeword is an optional function for LCS location services to protect UE against third party monitoring his/her 
location. 

The location request from the LCS client/Requestor may include the codeword for the target subscriber. The PLMN 
compares the codeword sent from the LCS client/requestor with the codeword, which is registered to the PLMN in 
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advance. If the comparison of the codeword is successful, then the location request is not rejected. If the comparison 
fails, the PLMN judges that the location request shall be rejected. After the codeword is checked and the check is 
successful, the privacy setting in the current specification will be checked. The privacy setting in the current 
specification is not overridden even if codeword check is successful. The codeword is registered in the PLMN by the 
subscriber. The subscriber may register multiple codewords. In this case, the location request is not rejected if the 
received codeword is included in the codeword list of the subscriber. The subscriber of the UE is responsible to 
distribute his/her codeword to such requestors, whom the subscriber has allowed to request his/her location. Once the 
codeword has been set and properly distributed, the subscriber is protected against the location request from a third 
party that does not know his codeword. 

Optionally, the subscriber may specify that the codeword is not checked in the PLMN, but instead be passed to the 
subscriber as additional information to be used by the subscriber to determine whether or not the location request should 
be authorized. 

The mechanism for distribution of the codeword to the requestors and registration of the codeword by the UE subscriber 
with the operator is outside the scope of 3GPP. The mechanisms to generate the codeword are not yet described in this 
Technical Report and it is for further study whether the mechanisms need to be standardized. The codeword is 
applicable to the value added services only. 

The codeword may be checked by the user of the UE or by the network. 

TS 22.071 [1] specifies the service requirements for the codeword function and the codeword functionality is part of 

Rel-5 . 



5.7 Anonymity 

For enhanced privacy the subscriber's true identity (MSISDN) can be hidden and replaced with an alias that is used as a 
permanent or temporary reference of the subscribe r, both when being a target and when being a requestor . As one 
solution t The alias can be passed on from the terminal to the LCS Client application when the subscriber invokes a 
request e.g. to a specific service type. As another solution, a som e secured network proxy may allocate the anonymous 
ID (alias) to replace MSISDN. The LCS client will use alias as an-identifiers for the target subscriber instead of using 
the true MSISDN identity. GMLC will in respons e- use the same alias , when sending the response to the LCS client . 
It should be possible to define both permanent and temporary alias. 

The service requirements for anonymity are to be discussed and agreed in SA1 and specified in TS 22.071 f 11 for Rel-6 . 

5.8 Related privacy issues in Presence and Location services 

Location information is an important part of the Presence information used in the Presence service. The subscriber 
should bo able to set privacy requirements also lor the location information used in the Presence service. Preferably the 
privacy settings and control mechani s ms that the subscriber has defined for location services should bo applicable as 
s uch al s o for th e location information in Pr e senc e s e rvices. 

Privacy settings for pr e s e nc e could possibly b e shared with LCS, but it nood further discussion is need e d between 
pr es ence and LCS p e opl e . 

Th e relations betwe e n privacy issues in presence and in LCS should bo discussed in SA1 and SA3. 



44^ Common stage 2 privacy issues i n Presonco and 

Location services 

The Presence service may act as a-LCS client and request location information from GMLC. The target mobile user 
shall he able to define privacy rules for the Presence server, as being an LCS client. The location request and privacy 
are handled as specified in 23.271 for this LCS client. 

The presence information (including location information) is used according to privacy settings as defined for the 
presence service. 
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If the watchers are trying to obtain the presence information including location information of the presently via 
presence service the following three conditions have to be met: 

1 . The Presence service must be set up as an LCS Client in the Location services, so that the Presence service cap, 
get the location of the Presentity. 

2. Presentitv has to set the access rules to allow the particular watcher to see the presence information (including 
location). 

3. Location services must be provisioned for the presentitv and the Presence service has to be included in the 
subscriber's (presentity's) LCS Privacy Profile fSLPP) / The Pr e s e nc e se rvice its e lf may r e quest from th e 
location s e rv e r what ar e th e privacy s e ttings that shall be applied for th e location information of th e targ e t 
mobil e before forwarding location information or oth e r pr e s e nce attribut e s to other parties. 

Possible differenc es b e tw ee n privacy settings in presenc e and in LCS should be r e solved. 



5.9 Summary of enhanced user privacy in location services in 
Rel-5 and Rel-6 

Table 5. 1 summarizes the enhanced user privacy features in Release 5 and Release 6. 



Table 5.1; Enhanced user privacy features in Release 5 and Release 6. 



Feature 


In Release 5 


In Release 6 


Comment 


Service Type Privacy (5.1) 


Yes 


Yes 


may need to be further 
elaborated for Rel-6 


Flexible privacy settings 
(5.2) 


No 


To be developed for Rel-6 




Requestor (5.3, 8) 


Yes 


Yes 


may be enhanced in Rel-6, 
see chapter 8 


Codeword (5.5) 


Yes 


Yes 


may need to be further 
elaborated for Rel-6 


Anonymous target and 
anonymous requestor (5.7) 


No 


To be developed for Rel-6 





There may be differences in the network support for enhanced user privacy in Rel-5 and in Rel-6. The Rel-6 solutions 
should be developed taking in account interworking with pre-Rel-6 releases. 



6. Network support for user privacy in Rel-5i 
descr i pt i on of sorvico typo privacy 

The service requirements for several enhanced user privacy features have been specified for Rel-5 and these features are 
su pported by the network in Rel-5 as listed in chapter 5.9. The Rel-5 enhanced privacy features are shortly described in 
this TR for comparison reasons, hut the corresponding LCS specifications contain the complete documentation of the 
su pported features, see TS23.27 1 . 



6.1. Network support for Service Type and Codeword in Rel-5 

LIF has defined a 'Service Identity' information element, which is used to identify the services offered by the LCS 
client. The LCS client shall forward the service identity information in the LCS Service Request on the Le interface 
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from the LCS cli e nt to the GMLC. It i s for further study whether t The GMLC or PPR (privacy profile reg i ster) shall 
map the received service identity to a specific Service Type when the service is provisioned in GMLC. The supported 
Service Ty pes in Rel-5 are specified in TS22.071. If GMLC only receives the LCS client identity but not the service 
identity, the GMLC may report an error to the LCS client, or in case the LCS Client is explicitly so authorized, proceed 
with the request. The service type information may be included in HLR/HSS and in the Privacy Profile Register . Also 
the Provide Subscriber Location MAP message sent by GMLC on the Lg interface to MSC and SGSN may contain the 
Service Type information. 

In order to support the service requirements for service type and codeword in Rel-5. the LCS architecture as specified in 
LCS stage 2, TS 23.271 Rel-4 is used, without any addition of new nodes/network entities. 

Th e service typo can be defined in a similar way as Annex C in TS 22.071 , wh i ch de s cribes the attributes for specific 
serv i ces. 

Th e se rvice typo privacy sotting could be tho same as the 5 privacy s e ttings listed in Ann e x A of 23.271, but in addition 
it may be necessary to define somo new privacy settings according to serv i ce typo. 

6.2 Network support for Requestors in Rel-5 

TS 22.071 111 specifi es a new service requirement in Rel-5. that the Location Request issued by the LCS client should 
be enhanced to opti onally include also the identity of the originator of the location request, i.e. the requestor not only 
the identity of the LCS client. In Rcl-5. if the LCS client provides a requestor identity, the GMLC shall send it as 
separate information . In addition, in order to display the requestor identity in case of pre rel-5 network elements (i.e. 
MSC and/or UE), the requestor i dentity may be also added to the LCS client name bv GMLC (this is supported in Rel- 
5). The requestor indication is further described in chapter 8. 

&tA Privacy profil e r e gist e r (PPR) 

The PPR as usod in tho architectural alternatives of clauso 7.1 and 7.2. contains a database with th o subcribors privacy 
information and p e rforms tho related privacy checks and reports the result to tho requesting entity. 

It is FFS and dependent on the architectural alternative, if tho PPR should also ho used for mapping of tho service 
identities exchanged betwo o n LCS cli o nt and GMLC to service typos used for roaming sc e narios. 

It is FFS, if the PPR should b o used for interoporations between LCS and other services, e.g. pr cs onc o s e rvice. 



7. Network support for Staa o 2 d e scription of finhann^H 
privacy checking in Release 6 

LCS Stage 2 specification TS 23.271 defines only ajimited set of privacy options in chapter 9.5.3 consisting mainly of 
five different privacy settings: 

• positioning not allowed; 

• positioning allowed without notifying the UE user (default case); 

• positioning allowed with notification to the UE user; 

• positioning requires notification and verification by the UE user; positioning is allowed only if granted by 
the UE user or if there is no response to the notification; 

• positioning requires notification and verification by the UE user; positioning is allowed only if granted by 
the UE user. 

These settings in the network are probably too limited to support the increasing number of LCS clients and the varying 
privacy requirements for location services especially for roaming subscribers. 
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It should be possible to have variable privacy settings, e.g. according to time of day, day of week and according to the 
location of the target UE. However, for compatibility reasons to Rel-4 the MSC/SGSN and HLR privacy functionality 
has to be kept to support {notification and/ verification}. 

Note 1: It is FFS if these additional privacy settings could be handled by the User Profile services as specified in 
3GPP. 

In order to keep the compatibility with pre- Re 1-64 privacy functionality (notification/verification), the concept of 
"pseudo-external identity" is used in Rel-6 and later releases introduc e d . In the current stage 2 specification 23.271 , the 
external identity is defined as the identity of external LCS client. The pseudo-external identity is not the identity of real 
external LCS client but the identity* which is used for notifying SGSN/MSC of the location request class (call/session 
related or non-related) and the required type of indication for the target UE user. The pseudo-external identity shall be 
defined by each operator. Eight pseudo-external identities shall be defined according to the type of indication and the 
location request class (call/session related class or not). The eight pseudo-external identities are summarized in the table 
1. Operator allocates E.164 addresses for the pseudo-external identities. 



Table 1 : Pseudo-external identities 



Pseudo-external identity 


Llocation request class 


Ttype of indication 


Pseudo-external identity 1 


Call/Session related class 


Location allowed without notification 


Pseudo-external identity 2 


Location allowed with notification 


Pseudo-external identity 3 


Location with notification and privacy 
verification; location allowed if no 
response 


Pseudo-external identity 4 


Location with notification and privacy 
verification; location restricted if no 
response 


Pseudo-external identity 5 


Call/Session non-related class 


Location allowed without notification 


Pseudo-external identity 6 


Location allowed with notification 


Pseudo-external identity 7 


Location with notification and privacy 
verification; location allowed if no 
response 


Pseudo-external identity 8 


Location with notification and privacy 
verification; location restricted if no 
response 



Note: More pseudo identities may be required. 

The pseudo-external identities are registered in HLR/HSS as SLPP of each UE in advance. 

When a GMLC receives a location request, the GMLC performs the privacy check, may-be with PPR. In case negative 
result of the privacy check, the GMLC immediately returns the response back. In case positive result, in order to 
indicate SGSN/MSC which type of indication (notification/verification) is required for the location request, the GMLC 
selects a proper pseudo-external identity according to the privacy check result. Then the GMLC replaces the external 
identity to the selected pseudo-external identity. The original external identity may be included in the LCS client name 
field if the operator want to notify the UE of not only original LCS client name but also the original identity. Then the 
GMLC sends Provide Subscriber Location message to MSC/SGSN as specified in 23.271. The SGSN/MSC selects the 
type of behavior according to the SLPP of the target UE and the pseudo external identity. 

With the pseudo-external identity, it is possible to enable the Rel-4 MSC/SGSN to behave according to the result of the 
enhanced privacy check mechanism without any modification of the Rel-4 SGSN/MSC. The pseudo-external identity 
also enables to handle the call/session related class. 

Even in the case when the target UE wants to be protected by the enhanced privacy check mechanism and the original 
external identity is replaced by the pseudo-external identity, the target UE can receive the client name of the LCS client 
to identify the LCS client. In the case when the target UE does not want to be protected by the enhanced privacy check 
mechanism and the HSS stores the SLPP including the original external identity list, the original external identity is sent 
to the target UE as previous release. 

Even with the pseudo-external identities shown above, the enhanced privacy parameters (i.e. Requestor ID, Codeword 
and Service Type) cannot be notified to the target UE, when the SGSN/MSC is Rel-4. 

It should be noted that the network nodes and interfaces in the alternative network solutions described below may use 
the same name e.g. for different interfaces. 
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7.1 Architecture alternative with privacy profile register (PPR) 
7.1.1 Architecture 

In order to support additional privacy settings for location services the HLR/HSS may indicate that the subscriber's 
additional privacy information for location services is available in an external database, e.g. the Privacy Profile Register 
(PPR). The PPR may contain additional privacy settings, e.g. according to time of day, day of week and according to 
the location of the target UE. In case the PPR have executed the additional privacy check and given the result back to 
GMLC, then GMLC will in case of positive result from PPR forward the Location Request to MSC/SGSN as specified 
in 23.271 or in case of negative result from PPR immediately return the response back to LCS Client. The PPR is 
accessible from the GMLC via the Lr interface. This is illustrated in figure 7.1. 
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Figure 7.1.1; LCS architecture alternative with PPR attached to GMLC 

The PPR is normally managed by the PLMN operator and there is trusted signaling between GMLC and PPR. When the 
request has to be delivered via an unsecured network, (e.g. the public IP-network) the PPR server needs to be 
authenticated and the traffic has to be secured. 

The PPR could be located outside the operator's core network, but this type of architecture is outside the scope of 
3GPP. 

Privacy check according to Rel-4 and Rel-5 (privacy check in MSC/SGSN) and the additional "privacy check" of 
GMLC/PPR (as described in this TR) may lead to different results 

GMLC sends the privacy check request to PPR. If the privacy check was approved by the PPR it will report to GMLC 
whether the subscriber wants to be notified, verified or whether the request is allowed without notification. GMLC will 
use this result and pass it on to the MSC/SGSN as an additional "result" field in the PSL message on the Lg interface. 
There are 3 alternatives how to combine the PPR result with the privacy checking in MSC (Rel-65): 



1. MSC shall check as specified in TS 23.271, whether the subscriber has blocked all LCS services, in which 
case the PPR result shall be rejected. In all other cases the PPR result shall be used as described in 
alternative 3 below, see note 3. 
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2. MSC shall also perform a privacy check as specified in TS 23.27 1, Rel-4 or Rel-5 as applicable, in the | 
following cases: 

PPR result is not received or MSC does not understand the result. 
PPR result is received but not used. 

3. MSC receives the PPR result and shall start MT-LR according to the result, see note 3. 



All the alternatives are configurable result handling routines. MSC can be configured so that one of alternatives I, 2 or 
3 is defined as default routine for each GMLC that is allowed to request for location from this MSC. MSC verifies what 
GMLCs are allowed to do location as defined in TS 23.271 . The HLR sends the PPR address per subscriber in the SRI 
response to GMLC and when a PPR is indicated, the GMLC may select that the privacy check is to be performed in the 
PPR pointed out by HLR. The Home PLMN operator is able to define what is the physical address of the logical entity 
PPR. The operator may even allow the subscriber to specify the location of the PPR and define the corresponding PPR 
address in the HLR/HSS 

This solution is especially feasible in roaming situations, since the PPR address is received from the HLR/HSS and the 
privacy is always checked in a single point that holds the subscriber's privacy rules. 

With this architecture alternative, when the PPR holds all the subscribers privacy information and if the privacy check 
fails the location request can be rejected already at that point. This means that there is no need to send the location 
request further to MSC/SGSN This functionality hence reduces the MSC/SGSN and the Lg interface capacity load. 

The privacy settings in HLR and PPR shall be consistent with the privacy settings in PPR, but this is seen as a network 
management issue outside the scope of this TR. 

If the GMLC supports this enhanced privacy check functionality including the Lr interface it should inform HLR about 
this in the SRI procedure. If HLR does not receive such information -it can anticipate that the enhanced privacy check | 
could not be handled. HLR can in this case select to reject the location request if necessary or send routing information 
to GMLC. 

Note 1 : SA3 will investigate d asked to verify whether the preferred solution alternative is acceptable from | 
security point of view. 

Note 2: It should be defined in MSC/SGSN what is the level of trust that MSC/SGSN can apply for the privacy 
setting result sent by GMLC/PPR, also when GMLC is in another country. This can be done using result 
handling routines 1 and 2, as described above. 

Note 3: GMLC includes in the privacy request to PPR an indication whether the Location request is call/session 
related or not. 

Note 4: In case of deferred MT-LR^_ it is FFS if the MSC should ask via the GMLC to ask the PPR to make the 
privacy check again, because the s ubscriber may have changed the LCS privacy information during the 
time when the target mobile wa s not available PPR will notify GMLC to make a new privacy request for 
the corresponding target mobile, if the user has changed privacy settings and there exists ongoing location 
request at the moment . 
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7.1.2 Information Flow 
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Figure 7.1.2; General information flow for the architectural alternative with the PPR attached to GMLC 
*Note 1. The Enhanced Privacy Check Request may contain the codeword and the service type. 

*Note 2. The Requestor ID and the codeword shall be sent to the MSC/SGSN if they are wanted to be shown to the UE 
user in the LCS notification invoke procedure. Also the privacy check result shall be carried to the 
MSC/SGSN. 



7.2. Architecture alternative with privacy profile register (PPR) 
attached to MSC/SGSN 

7.2.1 Architecture 

In order to support additional privacy settings for location services the HLR/HSS may indicate that the subscribers 
additional privacy information for location services is available in an external database, e.g. the Privacy Profile Register 
(PPR). To support these additional privacy settings (e.g. settings concerning service type, requestor ID etc.) in case of 
national and international roaming, the PPR is accessible from the MSC/SGSN via Ld interface. 

The privacy checks according Rel-4 privacy settings remain in the MSC/SGSN, the classification of the location request 
- call related/unrelated, PLMN operator - as well as the overall control of privacy checks - notification, verification, 
(emergency), privacy override - may be still located in the MSC/SGSN. In case the PPR has executed the additional 
privacy check and given the result back to the MSC/SGSN, the MSC/SGSN may decide - possibly dependent on 
information about whether the UE is in its home PLMN or it is roaming - how the result of Rel-4 or Rel-5 checks and 
the result of the additional privacy checks have to be merged (decision concerning verification/notification etc.). 

The address information of the referring PPR is stored in the privacy data of the subscriber in the HLR/HSS. In this way 
the PPR is known to the (visited) MSC/SGSN in case of national or international roaming. The PPR contains all 
privacy data or - for Rel-4 compatibility reasons - only the additional privacy settings. The PPR may contain only data 
of subscribers belonging to that PLMN. 

For synchronization purpose between PPR and HSS/HLR concerning possible common privacy data the PPR may be 
connected to HLR/HSS via Lt interface. This interface may also be used for change of privacy settings e.g. by means of 
a SCI procedure through HLR/HSS. 
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Determiroation of a call or a session to a LCS client to which the UE has an active connection is done in the MSC or 
SGSN respectively. This information will be applied for the call/session related privacy checks in the SLPP of Rel-4 4 
Re I -5 and the Rel-65 enhancements in PPR accordingly. 

The notification and verification settings for the enhanced privacy check in the PPR are reported as result to 
MSC/SGSN, where the according procedures towards the UE are initialized. 

Note t: With this architecture enhanced privacy checking in case of national and international roaming is 
possible. 

Note 2: The Rel-4 and Rel-5 compatibility is given within this architectural proposal. 

Note 2: As requested by the WT (SP-010574) this architecture allows the user easily to set or change the location 
related privacy parameters in the home network / PPR. 




Figure 7.2.1; LCS architecture alternative with PPR attached to MSC/SGSN 
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7.2.2 Information Flow 



Requestor 



l Ser ice Request 



(wit! 



enha iced privacy check) 



Client 



parameters for 



II. Service Respou e 



GMLC 



2. LCS Service Requ si 



(Parameter for 



njjnal pri vacy check) 

3. Send Routing Info for LCS 



10. LCS Service Respo ise 



PPR 



4. Send Routing Info 



orLCSack 



5. Provide subscriber 
(Parameter for enhanced pri vacy check) 



HLR/ 
HSS 



6. Enhanced Pri vac 



(Result of enhanced 



9. Provide si bscriber location ack 



MSC/ 
SGSN 



Check Request 



^Parameter for enha iced privacy check) 



7. Enhanced Pri vac Check Response 



privacy check) 



RAN 



LIE 



8. NonraJ procedures for CS and PS MT-LR. 



Figure 7.2.2; General information flow for the architectural alternative with the PPR attached to MSC/SCSN 



7.2.3 Exceptional handling 

KrwTi? 68 f ° r Tdoo deferred MTLR may h3Ve been chm « Ba while waitin g for «•» ^ent: For this, the 
MSC/SGSN shall access the PPR again, when the event is detected. 

7.3. Architecture alternative with Home GMLC 
7.3.1 Architecture 

adSL? SUpP ° rUh f e enhanced Privacy settings for location services the HLR/HSS may indicate thai the subscribers- 
additional privacy information for location services is available in a particular GMLC, i.e. Home GMLC of the 
subscriber. The Home GMLC may contain additional privacy settings of the subscriber, e.g. according to time of day 
day of week and accordmg to the location of the target UE. The HLR/HSS sends the Home GMLC addresser 
subscriber in the SRI response. The Home PLMN operator defines what is the physical address of the logical entity 
Home GMLC In case a GMLC, (originated GMLC), which receives a location request from an external LCS St 
received the Home GMLC address of the target UE from the HLR/HSS and the address is not the same aste own 
address, the ong.nated GMLC forwards the location request received from the external LCS client to the Home GMLC 
via Lr interface. Then the Home GMLC performs the enhanced privacy check. In case positive result the Home GMLC 
selects a proper pseudo-external identity, according to the required type of indication and the LCS privacy class 
(call/session related class or non-related class) of the location request, and replaces the external identity to the 
SSwSF* T^o 11 ^;? 6 " H ° me GMLC Sends Provide Subscriber Location message to 
M ^ S S 35 $PeC,f,ed 23 27 1 • If ,he tar 8 et user ' s P ri vac y setti ng does not require the enhanced privacy check 
and he HSS stores the SLPP including the original external identity list, the Home GMLC does not replace tne external 
dent.ty and sends Prov.de Subscriber Location message wi.h the original external identity. The Home GMLC forwards 
the location report received from the SGSN/MSC to the originated GMLC. In case negative result of the enhanced 
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privacy check, the Home GMLC immediately returns the response back to the originated GMLC The Home GMLC 
communicates with other GMLCs via the Lr interface. This architecture is illustrated in figure 7.3. 

If a GMLC supports the enhanced privacy check functionality including Lr interface, it should send that information to 
HLR in SRJ procedure. If that information is not received the home operator can then know that the enhanced privacy 
check could not be handled and the location request could be rejected already by the HLR. 

With this architecture alternative, the Home GMLC holds the subscribers privacy information and if the privacy check 
fails the location request can be rejected already at the Home GMLC. That would mean that there is no need to send the 
location request further to MSC/SGSN. This functionality would reduce the MSC/SGSN and the Lg interface capacity. 

When the Home GMLC concept is introduced, the deferred MT-LR is handled as following steps. 

Step l: When any privacy setting of a UE, which is held in Home GMLC of the UE, is changed, the Home GMLC 
checks whether there is any deferred MT-LR process related to the UE that the Home GMLC is waiting the 
event occurrence. 

Step 2: If there is a deferred MT-LR process, where the GMLC is waiting for the event to occur, the Home GMLC 
checks whether it is necessary to cancel the deferred location process in SGSN/MSC. 

Step 3: In case it is necessary to cancel the deferred location request the Home GMLC sends Provide Subscriber 
Location message to the SGSN/MSC in order to cancel the deferred location request process and returns 
response back to the original GMLC. 

This solution is especially feasible in roaming situations, since the Home GMLC address is received from the HLR/HSS 
and the enhanced privacy check is always done in a single point that holds the subscribers* enhanced privacy settings. 

The Home GMLC may hold both of the enhanced privacy settings and Rel-4 and Rel-5 privacy settings Rel-4 and Rel-5 
privacy checks in SGSN/MSC areis performed as in the previous releases in order to decide the type of indication for 
the target UE. 

Note l : The Home GMLC could not identify whether the location request is related to the ongoing call/session 
because the Home GMLC does not know about the called party number or APN of the ongoing 
call/session. The call/session related class shall be handled at SGSN/MSC as same as the current 
specification. 
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Note 2. It may be necessary to ensure that there is no inconsistency between privacy settings in HSS and Home 
GMLC when the Home GMLC will hold both the enhanced privacy settings and the legacy privacy 
settings. The synchronization of the privacy settings between Home GMLC and HSS could be realized by 
using O&M functionality or by using enhanced Lh interface. This is FFS. 



7.3.2 Information Flow 
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Note : In step 6, the Requestor ID and the codeword shall be sent to the MSC/SGSN (Rel-5 and Rel- 61 if thev are 
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The Home GMLC may in step 6 send also a pseudo-LCS client identity to MSC/SGSN of Rel-4 or earlier This 
signaling step should be further detailed. 
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7.4 Architecture alternative with PPR associated with the HSS only 



Section 7 4 was removed as other architectural alternatives consider similar mechanisms to what it introduced This 
done with the aim to simplifying the consideration and decision of the alternative methods. 
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Figure 7.5. J; General information flow when using existing architecture 



1. Th e LCS s e rvic e r e qu e st s e nt from the LCS Cli e nt to th e GMLC carries the paramet e rs for enhanced privacy 

ch e cks (R e qu e stor Id, Codeword and Service ID). 

2. The GMLC verifi e s in th e LCS cli e nt profile that th e service ID r e ceiv e d by th e LCS client matches one of the 

allowed Serv i c e id e ntiti es fo r tha t L C S cli e nt. 

3. Th e GMLC s e nds a Send_Routing_Info_for_LCS message to th e HLR/HSS, carrying th e cod e word rec e ived 

from th e LCS cl ie nt. 

l.The HLR/HSS verifi e s that me Codeword r e c e iv e d from th e GMLC matches one of th e codewords stor e d for th e 
target subscriber, if the check is unsuccessful, the HLR/HSS s e nds an error indication to the GMLC and the 
LCS proc e dur e is e nded. If the check is successful, the HLR/HSS may verify that th e VMSC supports the EUP 
m e chanisms (this information is received in th e HLR/HSS at location update in the *'LCS supp o rt e d 
capab i lities s e t")- I" ord e r to prot e ct th e privacy of a roaming subscriber, th e HLR/HSS may r e j e ct th e 
Send_Rout i ng lnfo_for _LCS i f the VMSC/SGSN do e s not support e d enhanced privacy checks. If the 
codeword check is successful and th e VMSC/SGSN supports the need e d LCS capabil i ties, the HLR/HSS s ends 
the VMSC/SGSN address in Send_Routing_Info_for_LCS_ack mes s age. 

5. If no cod e word is r e gi s t e red in the HLR for th e subscriber, th e HLR shall not reject th e requ e st and inform th e 
GMLC by s e tting the cod e word check info in th e Send_Routing_Info_for_LCS_ack m e ssage 
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Figure 7.5.2; Continued general information flow when using existing architecture 

6.Tho GMLC converts tho s ervice identity r e c e ived by tho LCS client in tho proper s ervice typo and sends the 
service typo and the R e questor identity in the MAP Prov i de Subscriber Locat i on messag e . If th e GMLC 
received tho information that no codeword for the subscriber was stored in tho HLR. tho codeword shall bo 
include in tho Provid e Subscriber Locntion mnr^npo, in nrrW tn have th" rofli^v ord che c k in tho UE (noto that 
the PSL message has to carry the codeword for notification, not depending of the chosen architecture) . 

7.1f the SLPP contains s e rvice types/r e questor ids, an CS MT LR/PS MT LR will bo allowed by th e MSC/MSC 
s erver or SCSN if the service typ e /r e que s tor id suppli e d by tho GMLC matches th e identity of any service 
type/requestor id contained in th e UE's SLPP. If tho SLPP docs not contain service typos/requestor ids, th o 
alr e ady existing privacy check s will b e performed. 

8.1f notification has to be perform e d, th e LCS Notification Invoke m e ssage will carry also th e requestor ID, the 
service type and th e cod e word, if rec e iv e d. 



7.6-5_ Comparison between each architectural alternatives 

Several architectural alternatives are proposed in Chapter 7. This section was set up for the comparison of network 
alternative s in Rel-5 and is not fully applicable for Ret-6 comparos tho propn r. nH arehiteetwal n l i er nnti ve s . 

Table 7.5.1; Comparison from operator's point of view. (See Note) 
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Note: The criteria is whether an operator can protect the operator's subscribers against location requests, which needs 
enhanced privacy check. The operator may reject a Rel-4 location request in a Rel-5 network. 
The Rol 5 GMLC includ es a notification to HLR that it supports e nhanc e d user privacy. 



SGSN/MSC 


Rel-5 


Rel-4 or earlier 


Rel-5 


HLR 


Rel-5 


Rel-5 


Rel-5 


GMLC 
which 

received the 
location 
request from 
LCS client 


Rel-4 or earlier 


Rel-5 


Rel-5 


1A . > / - 
PPR attached. 

, ! i A i ■ \f, fet i% 

to GMLC 


Yes 

If the operator wants to protect 
operator's subscriber against 
unwelcome location request, 
HLR needs to reject SRI from 
the GMLC because the 
enhanced privacy cannot be 
checked. HLR may reject SRI 
from the GMLC depending on 
the setting in HLR 

The GMLC cannot access the 
PPR 


Yes 

Enhanced privacy check is 
performed in the PPR and the 
PPR rejects the unwelcome 
location request. 

GMLC will use in PSL request 
to MSC a Pseudo LCS Client 
ID that it receives from the 
PPR to provide backward 
compatibility 


Yes 

Enhanced privacy check is 
performed in the PPR and the 
PPR rejects the unwelcome 
location request. 


pPR^attached^ 

•'to V 

• -* . * * 
MSC/SGSN. 

.;; , . ;T -: .. - 

• : *' < 

1 1 11 ) : 


Yes 

Rel-4 privacy checks remain in 
MSC/SGSN and are possible 

If the operator wants to protect 
operator's subscriber against 
unwelcome location request, 
HLR needs to reject SRI from 
the GMLC because the GMLC 
cannot send some parameters 
for enhanced privacy to the 
MSC/SGSN and the 
MSC/SGSN cannot check the 
enhanced privacy by using new 
parameters (i.e. codeword, 
requestor id, service type, etc) 


Yes, 

the HLR may reject the SRI if 
the MSC/ SGSN does not 
support the proper LCS 
capability set. 

The Pseudo Id cannot be used. 

The MSC/SGSN cannot access 
the PPR and rejects the request 
due to Rel-4 incompatibility 
reasons. 


Yes 

Enhanced privacy check is 
performed in the PPR and the 
PPR rejects the unwelcome 
location request. 




The MSC/SGSN can access 
the PPR, but the MSC/SGSN 
cannot obtain some parameters 
sent from the LCS client 
because the GMLC does not 
support Rel-5. 






Home 
GMLC 


Yes 

If the operator wants to protect 
operator's subscriber against 
unwelcome location request, 
HLR needs to reject SRI from 
the GMLC because the 
enhanced privacy cannot be 
checked. The GMLC cannot 
access the Home GMLC and 


Yes 

Pseudo Id are used towards 
Rel-4 MSC/SGSN. 

Enhanced privacy check is 
performed in the Home GMLC 
and the Home GMLC rejects 
the unwelcome location 
request. 


Yes 

Enhanced privacy check is 
performed in the Home GMLC 
and the Home GMLC rejects 
the unwelcome location 
request. 
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SGSN/MSC. 






7.4 

PPR-HSS 


NA 


NA 


NA 


Chapter 6 = 

architecture 

i j K - ; • 


Yes 

If the operator wants to protect 
operator's subscriber against 
unwelcome location request, 
HLR needs to reject SRI from 
the GMLC because the 
enhanced privacy cannot be 
checked. HLR may reject SRI 
from the GMLC depending on 
the setting in HLR, so the 
GMLC could not access the 
SGSN/MSC 


Yes 

HLR may reject SRI if the 
MSC/SGSN does not support 
the proper LCS capability set. 


Yes 

Codeword is checked in the 
HLR-GMLC in HPLMN and 
the HLR rejects the requests if 
the codeword check is not 
performedsuccessful or the 
MSC/SGSN does not support 
proper capabilities 



Table 7.5.2; Other criteria 

Note: The Network Scenario for this table is that GMLC, HLR, MSC/SGSN are all Release 5 (except column 2). 



lltllgii: 
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liliiil: 


Enhanced support ; 
for location 
information privacy 
in other services e.g. 
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Generic User Profile 


The operator can 
provide the enhanced 
Rel-5 privacy 
mechanisms to the 
Target LTE subscriber or- 
not in the Rel-4 
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Gall/Session related 

aass mm 

(Note 2) 


Deferred MT-LR (Note 

Handling: of -event- 
based LCS (Note 4) || 

.- - ' -': 


■ 4 :; M%m, 
71 , m 

' 2j ■ m: 
PPR attached! 
to GMLC 

■■•HI WMm 


FFS 


Yes for enhanced 
privacy check in 
network. 
The operator can 
provide the en-hanced 
privacy mechanism 
even if the MSC/ SGSN 
is Rel-4 using pseudo 
id. 

No in the sense that 
codeword, service type, 
requestor are not shown 
to target UE. 


Yes 

PPR can send two 
results: 

- call/session 
unrelated and 

- call/session 
related 

MSC/SGSN shall 
confirm if the request is 
call/session related 


Yes 

VMSC/SGSN might 
have to contact PPR in 
the HPLMN (depending 
on the event), carrying 
the information needed 
to perform privacy 
checks. 


•• . • . .•:::.:::<, ■■ • • 
- Y - i * '• 

7.2 

PPR attached 
to 

MSC/SGSN •. 


FFS 


Yes for codeword check 
in HLR 

No for other enhanced 
privacy checks. No in 
the sense that 
codeword, service type, 
requestor are not shown 
to target UE. 


Yes 

MSC/SGSN recognize 
the call/session related 
connections and can 
support it for the 
enhanced services 


Yes 

VMSC/SGSN might 
have to contact PPR in 
the HPLMN (depending 
on the event), carrying 
the information needed 
to perform privacy 
checks. 


7.3 

Home ; 
GMLC 


FFS 


Yes for enhanced 
privacy check in 
network. 

The operator can 
provide the enhanced 


Yes 

Call/Session related 
class is handled in 
SGSN/MSC. Home 
GMLC may replace the 
external client identity 


Yes 

When the enhanced 
privacy setting of the 
UE is changed, the 
Home GMLC cancels 
the deferred MT-LR 
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privacy mechanism 
even if the MSC/ SGSN 
is Rel-4 using pseudo 
ids 


to the pseudo-external 
client identity. 


dependent on the 
changes. 


■■„■' • . * ' "4. ■• : ■ 

: \ . . & ; 




No in the sense that 
codeword, service type, 
reouestor are not shown 
to target UE. 






7.4'-;*:'.-r- ^ 

ppr-;'hss 


NA 


NA 


NA 


NA 
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FFS 


Yes for codeword check 
at GMLC in HPLMN. +« 

HLR 

No for other enhanced 
privacy checks. No in 
the sense that 
codeword, service type, 
requestor are not shown 
to target UE. 


Yes 

(no impact) 


Yes_(no impact for 
deferred LR) 
For event based LR the 
VMSC/SGSN can 
perform privacy checks 
when the event occurs, 
basing on the event 
related information and 
SLPP. The SLPP would 
need to be updated. 



Note 2: The criteria is whether it is possible to handle the call/session related class in SLPP that is already defined in 
Rel-4 ^Specifications and to be enhanced for the Rel-5 privacy settings. If the PPR or Home GMLC does not 
stores the SLPP and the SLPP is checked in the MSC/SGSN, this issue is not caused. 

Note 3: The criteria is whether it is possible to reflect the new privacy setting changed during waiting the event 
occurrence of the deferred MT-LR. 

Note 4: In deferred location request the privacy check has to be performed when the event occurs. The criteria is the 
possibility to handle event-based LCS: for some events, the result of the privacy checks may depend on 
information owned by the VPLMN. When such new events are defined, the information has to be transferred to 
the node performing privacy checks. If privacy checks are performed in the HPLMN, the interfaces between 
the VPLMN and HPLMN have to be updated for each new privacy check. This shows that if the privacy 
checks are performed in the HPLMN, there will be anyway the need to update interfaces when new privacy 
checks are introduced. 

The description of the architecture alternatives might need to be changed to show how the privacy of deferred location 
requests is handled. 

Editor's not e : Table 7.5.3 b e low is th e sam e as in v e rsion 1 .1.0 of this TR. The d i scussion is st i ll to bo continued 
regarding th is tabl e . 



Table 7.5.3; Other differences between architecture alternatives 
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7.67 Conclusion on architecture for the enhanced privacy 
checking 

Editor's not e : The cont e nt of this chapter io not yet agreed- 
See chapter 13. Conclusion. 



8. Possible requestor enhancements in Rel-6 Stage 2 
descript i on of R e questor i nd i cation 

In Rel-6 the requestor concept could be further enhanced by introducing a so-called "Authorized Requestor List". The 
"Authorized Requestor List" is defined by the target user and not bv the operator as for the "Authorized UE List". The 
"Authorized Requestor List" may be used to control the access to location information even though the user is hot 
subscrihing to notification/verification, but still wants to control what requestors can get his location. 

TS 23.271 pre-Rel-5 defines a LCS Location Notification Invoke message sent to the target UE in a MT-LR both in the 
CS and the PS domain. This message indicates the type of location request and the identity of the LCS client and 
whether privacy verification is required. From target UE user point of view this reflects only part of the location request 
chain, i.e. a possible requesting entity remains unknown to the target UE user. This is considered as a flaw in terms of 
target UE user privacy in pre-Rel-5 . 

The identities of the rRequestor can be e.g. MSISDNs or logical names. Editorial not e : The requestor identity need 
perhaps not be globally unique, comp papa and Naomi. 

The LCS Location Notification procedure should be enhanced for transferring the rRequestor identity to the target UE | 
for a case-by-case authorization by the user. 

Functional ^Requirements: 

■ The requestor identity should be added as an information element to be carried on the Le, Lg and Lc interfaces. 

■ The requestor identity should be included in the location request, if available. When the originator of a location 
request is the LCS client itself, the LCS client may set the LCS client name as the requestor identity. 

■ When there is the originator as an independent entity of the LCS client and the LCS client does not have the 
requestor identity corresponding to the location request, some special value may be sent as the requestor 
identity. (The special value may be "empty".) The actual value of the special value is outside the scope of the 
present document. 

• Before the LCS client issues a location request on behalf of a requestor, the requestor identity shall be duly 
authenticated so that the target user can trust the displayed requestor name to be correct. 

■ The requestor identity should be added to the LCS Location Notification Invoke procedure 
Nolo: Anonymou s location rcqueGt is for further study. 
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8.1 Architecture alternative with requestor authentication in 
GMLC 



Figure 8.1 illustrates the MT-LR signaling procedure when the requestor identity is authenticated in GMLC. 
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Figure 8.1; MT-LR signaling procedure when the requestor identity is authenticated in GMLC 



1) A requestor entity is accessing an LCS Client requesting a service, which requires the location information of a 
target UE. {The interface requestor - LCS client is outside the scope of this TR.} The identity of the 
requestor may be added to the service request by the requestor. Another possibility is that the rRequestor 
identity is obtained from the LCS Client as the requestor is authenticated with the LCS Client. In this case the 
rRequestor identity also needs to be provisioned in the privacy profile. 

Note: According to this description, the requestor identity may be authenticated both by the LCS client and the 
GMLC in this case. 

2) The LCS Client issues a location request to the GMLC containing the identity of the rRequestor. 

3) Common PS and CS MT-LR procedure as described in 23.271 section 9.1.1 . After the authentication of the 
LCS Client and checking that the target UE is on the "Authorized UE List'*, the "Allowed Requestor List" is 
checked for authorization of the location request for this rRequestor. 

Note: More detailed description of steps 4 to 1 2 can be found in TS 23.27 1 , section 9. 1 .2 onwards. 
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4) The GMLC sends a PROVIDE. SUBSCRIBER .LOCATION message to the MSC/MSC server/SGSN 
indicated by the HLR/HSS. This message carries also the new ^Requestor identity information. If the target 
UE subscriber profile so indicates, the UE must be notified for privacy verification. The ^Requestor identity is 

included in the LCS Location Notification Invoke message together with the LCS Client Id. 

5) Described in 23.27 1 section 9. 1 .2. 

6) If the location request comes from a value added LCS client and the UE subscription profile indicates that the 
UE must either be notified or notified with privacy verification and the UE supports notification of LCS 
(according to the UE Capability information), an LCS Location Notification Invoke message is sent to the 
target UE indicating the type of location request (e.g. current location) and the identity of the LCS client, 
rRequestor identity and whether privacy verification is required. 

7) to 12) Described in 23.271 section 9.1.2 

13) The LCS Client sends the service response back to the requestor with the location information of the target 

UE. In case there was an error or the request was denied or not authorized this may be indicated in the service 
response. However, specification of the service response is outside the scope of this TR. 
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^2 Arch i toctur e alt e rnat i v e with requestor authont i cat i on in th o 

LCS cl i ent 

Figure 8.2 illustrator , th e MT LR s i gnaling proc e dur e svhen tho r e questor id e ntity i s authenticated in tho LCS cl i ent ? 
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Figure 8.2; MT LR signaling procedure when the requestor identity is authenticated in the LCS client 



1) A requestor e ntity is access i ng an LCS Cli e nt r e questing a service, which requires tho location information of a 

target UE. [The i nterface Requ e stor — LCS client is outside th e s cope of this TR.] The id e ntity of the R e questor 
may be added to the serv i ce r e quest by the requestor. Another possibility i s that th e Requ e stor id e ntity is 
obtained from the LCS C l ient as the requestor is auth e nt i cat e d with th e LCS Client. 

2) Tho LCS Client issue s a location request to the GMLC containing th o identity of the Requestor. 

3) Common PS and CS MT LR procedure as described in 23.271 section 9.1.1. 

Note: More detail e d information of stop s 4 to 12 can be found in TS 23.271 sect i on 9: 1.2 onwards. 

4) Tho GMLC send s a PROVIDE. SUBSCRIBER ..LOCATION message to the MSC/MSC servor/SGSN indicated 

by tho HLR/HSS. This m e ssage carries also the now R e qu e stor Identity i nformation. If tho target UE 
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subscriber profil e s o i ndicates, tho UE must bo notified for privacy verification. The R e questor identity i s 
included in the LCS Locat i on Notification Invoke message tog e ther with the LCS Client Id. 

.^Descr i bed in 23.27 I s e ction 9,1,3. 

6) If the location request comes from a value add e d LCS client and the UE subscription profile indicates that tho UE 

must e ither b e- notifi e d or notified with privacy verification and th e UE supports notification of LCS (according 
to tho UE Capability information), an LCS Location Not i fication Invok e messag e i s s ent to the targ e t UE 
indicating tho type of locat i on request (e.g. curr e nt location) and the i dent i ty of the LCS client, Requestor 
identity and wh e th e r privacy verification is r e quired. 

7) to 12) Describ e d in 23.271 se ction 9 . 1.2 

4-3-) — Th e LCS Client s ends th e servic e r es pons e back to tho requ e stor with tho locat i on information of the target 

UE. In case there was an error or tho request was denied or not authorized this may be indicated in th e service 
response. However, sp e cification of the servic e r e spon s e is outsid e th e scop e of this TR. 

8.32 Backward compatibility 

MSC, SGSN and UE according to previous releases do not support the requestor functionality. 

When a location request is passed through MSC, SGSN or GMLC of previous releases, the requestor identity of the 
location request may be dropped and UE may not be able to receive the identity. 

When a Rel-5 LCS client or Rel-5 GMLC is going to send a location request and the client or the GMLC does not have 
a requestor identity, which corresponds to the location request, the client or the GMLC should send some special value 
as the requestor identity of the request. (Note: The actual value of the special value is outside the scope of this TRt he 
present document .) When a location request, expected to contain the requestor identity, is notified to the UE without 
requestor identity, the UE is able to judge that the requestor identity was dropped due to the lack of network capability. 



A s an alternative, the requestor identity could be carried as part of the LCS client nam e . In this case, when an LCS 
client name, expected to contain the r e questor id e ntity, is notified to a Rel 5 UE without th e r e questor identity, the UE 
is able to judg e that th e r e qu e stor identity wa s not provided from the LCS client. But thi s alt e rnativ e is for furth e r study 



9-. Stage 2 doscr i pt i on of th e codeword conc e pt 

Ther e ar e thr ee ways to standardiz e the codeword handling. One way is that the codeword i s stor e d in th e GMLC and 
compar e d in th e GMLC. Anoth e r way is that tho cod e word is stored in die PPR and compar e d in th e PPR. A further 
s olution is that th o codeword is stored and compar e d in the HLR. Th e s e alternativ e s ar e described and compared in 
chap ter 7. 



4Q r9. Stage 2 description of the anonymity concept 

The stage 2 description is FFS. 
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44^ Common stage 2 pr i vacy issues in Prosorico and 

Location s e rvices 

Tho Presence service may act as a LCS client and request location information from GMLC. Tho location r e quest and 
privacy are handled as spec i fied in 33.271 for th is LCS cli e nt. 

Tho PrcGenco sorvico its e lf may r e qu e st from th e location server what arc the pr i vacy settings that shall be applied for 
tho location information of tho target mobile b e fore forwarding location information or oth e r presenc e attributes to other 
parti e s. 

Possible diff e r e nces b e tween pr i vacy s ettings in pre s ence and in LCS should b e resolv e d. 



104^. Charging Aspects 

No charging aspects have been identified. 



Security aspects 

The follo wing security aspects and security requirements have been identified: 

• It shall be possible to verify that the service identity indicated bv the LCS client is correct. The service types 

offered by a certain LC S Client is to be part of the LCS Client service profile, which shall be known bv the 
GMLC. An LCS client is hence not able to claim to offer services that are not included in its profile. 

• The servi ce type should only be conveyed between PLMNs with valid roaming agreements. 

• The requestor should be authenticated bv the LCS client. 

f According to current specifications the LCS client shall be authenticated bv GMLC and authorized based on 

information in HLR. 

^ The alias for an ano nymous target mobile or for an anonymous requestor shall be generated in a secure way T 

such that the real identity is never revealed to a third party. 

SA I has specified service requirements for the requestor. LCS client. LCS server and e.g. requirements to protect the 
privacy of the target mobile user. The security aspects of LCS are specified in TS22.Q7L chapter 4/7. 



1244. Roaming, Service Availability and Continuity 

There is a Work Item in t h e Rel-6 time frame regarding a new GMLC - GMLC interface to improve roaming support. 



BNSDOCID: <XP 2272724A_J_> 



3GPP 



ggj»gff>23j*71 V2.10.0 (2002^43}3gggjE^Ss H3 V2.1.0 i2002 - 0 ' n 3GPP TR 23.871 

* V2.10.0 (2002 - 0 4 3) 



13. Conclusion 

In Rel-5 tew new service requirements for LCS have been identified i.e. "Codeword", "Service Tvpe ?; and "Requestor' 
All these three concepts have been handled and included in Rel-5 LCS stage 2 TS (v. 5.2.0) by means of minor 
functional requirements on the existing architecture, without any need of new architecture. 

The current LCS stage 2 TS is also in iine with the existing Rel-5 service requirements concerning the privacy of 
roaming subscribers and allows protecting their privacy with Rel-5 mechanisms. In fact the HPLMN is aware of the 
LCS capabilities of the VMSC/SGSN by means of "Supported LCS capabilities sets" mechanism: the HPLMN 
(HLR/HSS) is aware of the VMSC/SGSN capability to support Rel-5 privacy checks and can have the full control in 
order to protect the privacy of subscribers roaming in a different PLMN. This means that if the VPLMN does not 
support Rel-5 privacy checks, the HLR may reject the LCS request, without any involvement of the VPLMN and/or 
useless signalling. 

A change in the architecture can be proposed in next releases when new service requirements that are not feasible to be 
implemented in the existing architecture are identified. The LCS network architecture in Rel-6 will take into account the 
GMLC-GMLC interface and will be guided by identified Rel-6 service requirements. 

The Technical Report will not be continued in Rel-6, instead the Rel-6 solutions will be discussed and agreed based on 
proposed CRs against LCS stage 2 specification 23.271 . 
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